Really Getting Started in Rails
Into JavaScript? Have I got good news for you!
If you’re interested in JavaScript-driven web apps, snazzy visual fx, and generally confusing people into thinking your site is Flash—but oh-so-much better—you should buy our JavaScript Performance Rocks! book while it’s still in beta. Written by Thomas Fuchs, the creator of Scriptaculous, and yours truly, the maker of funny jokes and shiny graphics.
We cover everything from The Most Ridiculous Performance Fix Ever (and it is ridiculous), to serving strategies, DOM diets, loop unrolling (for those really extreme cases), how to play nice with the garbage collector, and everything in between. And it comes with our custom profiling tool, The DOM Monster, which analyzes your pages and suggests fixes. This package is only $24 right now but will be $29 as soon as it’s done, in mid-June 2009… but if you snag your copy today, you get the final version by email just as soon as it’s ready and save a noteworthy 5 bux! You can’t lose.
Curt Hibbs has written Rolling with Ruby on Rails, a tutorial on Ruby on Rails for O’Reilly OnLAMP. (Amusing fact: LAMP is an acronym for the triumvirate+1 of Linux-Apache-MySQL-PHP. I am perfectly willing to admit that I am, in fact, easily amused, but I think that this is kinda funny.)
It’s a good tutorial. Good as it is, though, it’s not perfect (hell, what is?). But hooray for imperfection, because it spurred me to write.
The Review
It’s actually a pretty good article, the one with the most depth and breadth that I’ve seen at this point, and I used it to explore Rails last night. If you already know and understand programming concepts like database connectivity, object orientation, variables, loops, etc., then it’s a good place to start to get your hands dirty. After having actually produced some code, even if it was guided, I now have a better grounded understanding of Rails and that makes it easier to read the dry (not DRY, alas) documentation.
The only thing is, like all tutorials, it doesn’t always explain why. Why is that the syntax? What does that line mean, exactly? Why is the application designed so it fits together that way? Me, I like to know why—in reality, because of my designer brain, I have to know why to really grok it and retain it.
The Missing Minutiae
It’s true—I’m a little impatient, too. So in the interest of science, I’m running a little experiment, seeing if I can pick up Ruby on Rails without completely learning regular ol’ un-frameworked Ruby first. I’m learning as I go, and seeing how that works out. (I never could have done this before learning the aforementioned programming concepts, though, so if you don’t know them—and especially if you’re a right-brained designer-type like me—this is probably not the best way to go for you!)
Since I didn’t set myself down and read all (or even much) of Pick Axe II yet, there are (large) parts of Ruby that I don’t know off the top of my head, either. So I also used this as a chance to familiarize myself with the syntax —in a less theoretical way.
Variables: Where it’s At
For instance, I learned that in the line
@recipes = Recipe.find_all
the @ signifies that recipes is an instance variable. And for future reference, I learned that @@ signifies a regular old class variable. (And Tobi over at Leetsoft points out that global variables start with $. Ewww, globals!)
I already understood the rest of that line: Recipe is an object based off of the Recipes class (which uses the Recipes model), and find_all is one of the standard methods you’re able to use on such classes when you use Ruby on Rails’ ActiveRecord system. More on this later.
Syntax, Schmyntax
As you probably noticed, Ruby (not just Rails) has very lax rules when it comes to syntax. But without an explanation, you might not immediately realize how lax. (Hint: The answer is ‘very lax.’)
You don’t have to use semicolons—but you can. You don’t have to use parentheses—but you can. You don’t have to use curly braces on code blocks—although, of course, you can. Variables don’t start with $, either, unless they’re globals—but they do sometimes start with @ as we’ve seen.
I used to wrinkle my nose at code with so few constraints, especially the lack of variable signifiers (mmm, I like associating coding with $$$!) in languages like Python and Ruby. But I was wrong, and perhaps just a tiny bit scarred by my PERL experience. But Ruby is gorgeous—spare like a Japanese tea room, as functional as a Zen studio. I want to marry Ruby and have its babies. But I have the feeling that a language like Ruby lives a life that resembles its syntax; I’m sure it’s not looking for that kind of emotional entanglement. Somehow, I soldier on.
What’s in a Table Name?
For the magic of ActiveRecord to work, you must name your database tables and columns according to specific rules. For example, when you create a table, Rails wants it to be plural. Not story, but stories. And it wants the auto_increment primary key column to always be called id, case sensitive.
And when you want to create a one-to-many foreign key relationship between, say, authors (note the plural!) and stories, you have to use a column author_id in stories. The foreign key must be named in the format of: *singularOfForeignTableName*_id.
Ruby Tongue, Rails Groove
My designer brain likes an overview of how everything fits together; if I can’t visualize it all dovetailing like floorboards or puzzle pieces, I have a hard as hell time coming up with a solid design for my programs. (And if I don’t do a design/architecture phase before coding, I feel the need to self-flagellate with printed and bound copies of PHPNuke. Oh, you laugh now, but you should try it sometime.)
Unfortunately, this kind of View from 10,000 Feet information is another thing that most tutorial authors don’t discuss.
Rails’ Super Model
One of the things that really made me drool over Rails to start with was its use of ActiveRecord. ActiveRecord is a really spifftastic tool that allows you to describe your database and its data (together known as your database model) in Ruby code, and instead of having to write the same kinds of stupid repetitive queries (“select name,category_id from articles where id=5”) over and over, allows you to access your data in a representative way, right there in the code.
So when you’re writing your data model files in the tutorial, and you write something like:
class Recipe < ActiveRecord::Base
belongs_to :category
end
What you're doing is, in effect, duplicating an Entity-Relationship Diagram (ERD) of your data in code. Which means you can then access the data as an object in Ruby, instead of writing stupid queries. (Of course there will be times when you have to write queries because of ActiveRecord's simplicity, but nevertheless! It's still so damned cool!)
Of course you have to following the naming schema that I talked about earlier in order to even use ActiveRecord in this way.
Scaffolding is Fun!
Scaffolding is a feature of Ruby on Rails that I hadn't really, really appreciated until I tried it out. To understand scaffolding, you have to understand some basics about database-backed development, for example CRUD. In case you're not familiar with this archetypical example of devgeek humor, CRUD is shorthand for Create/Retrieve/Update/Delete, and it describes most of the basic operations you'll run into when developing a database-backed app.
Since most apps are centered at least partially around CRUD operations, and Rails already uses ActiveRecord to look at the database and figure out relationships (assuming you're a good little boy or girl and name your tables and columns accordingly), the powers that be decided to just take it one step further and create a generic set of methods and views to enable you to do CRUD operations immediately with a single line of code (after you create your model, anyway).
All you have to do is, after having created your controller and your model, write the following line:
scaffold :modelname
Models, Views, Controllers, Oh My!
Explaining MVC for the lay audience is something I'm not going to tackle right now, since I'm noticeably out of Mtn Dew Livewire and I'm scared of attempting to describe something as complex as design patterns without a little comfort from my chemical cohort. But I can at least make some useful (I think, anyway) points about the MVC-related file structure of Rails projects.
Update. I did tackle this project at some point! Be sure to read MVC: The Most Vexing Conundrum.
Rails is a real development framework. You run it the first time, and it creates a project folder for you, and in that project folder it creates another bunch of directories. One of the hallmarks of good code in web development scripting, especially in something like PHP, is an organized file structure. A file structure like that says to the third party viewer, "Hey, this person took the time to think out logically what files and components should go where, and they separated it out to make it easier for schmucks like me to understand. Cool."
The file structure Rails creates for you goes something like this:
app/
config/
db/
doc/
lib/
log/
public/
script/
test/
vendor/
app is another multi-tier directory, and inside you see the following:
app/
controllers/
helpers/
models/
views/
This is where you'll be doing most of your work. You create the database models in models, your controllers for each model in controllers (amazing!), and views for controllers to use in, well, the eponymous location. Thanks to the data relationship information in a given model, you can access data from multiple models in a single controller, as long as it's all related; and then, the controller can call any number of views, as long as there is a view named the same as the function that wants to call it.
So for
def list
end
The list.rhtml view will be called, if it exists. If it doesn't exist, ooh boy...
Rolling Your Own (Rails App)
Unfortunately, there doesn't seem to be an easy way to snag the scaffold code and mess with it. If there is, I'll find it soon, because I want to play with it and see what it looks like. Until then, if you want to go beyond the scaffold, you have to write all your own stuff from scratch. Luckily, that's not too difficult once you start grasping all the related concepts above and in the tutorial by Curt.
Stay Tuned... & In Touch
Because I'll be writing up more as I continue to learn and think about this stuff. If you have something particular you'd like me to write about, especially if it's in the realm of beginner information, leave a comment or pop by #rubyonrails on the IRC network irc.freenode.net and make some noise. My nick's eriberri.
You can mess with the scaffold code if you use Rails scaffold generator, instead of the scaffold macro. Go to the root of your Rails app, and type: ruby script\generate scaffold test And, voilla! You have the once invisible scaffold code materialized for you in your app folder! 😉
For table names, you can override by providing it as a parameter. Or you can hook in your own conversion.
For scaffolding, its often good to start using the scaffolding, then start implementing your own rhtml files for specific actions, i.e. list.rhtml, but leaving the others as default. Then overriding the action methods individually. If you find you have replaced all of them, then you can remove the scaffolding completely.
Thats one of the nice things about rails. Nice smart defaults, but you can override anything you want.
What a wonderful complement to my ONLamp article!
In general, I also want to know "why" to help enhance my understanding. Its a tough call in a tutorial-style article like this because if it gets too long, people will get discouraged to see a book-length tome. In the end, I opted to mostly demostrate the magic of Rails, hoping to pique the reader’s interest enough to make them want to dig deeper.
I will defnitely be pointing people here for more details on the whys of Rails and Ruby.
Thanks for writing this, and I look forward to reading the continuing updates of your exploits.
Curt
One thing I would’ve liked in the original article would be an SQL schema (dump, whatever you like). Just to make sure I had all of the things correct. I assumed I could do it using a different front end, but things got a bit tricky for me. (note: I also changed the example into my own convoluted thing I wanted to do, so there were/are a lot of uncontrolled variables)
I apologize if one was there and I just missed it.
Thanks to everyone for reading & responding. Hi Curt!
Rich, I don’t know if you meant this article or Curt Hibbs’ article (which spawned this one, sort of), but I’m working on a set of articles to do with database schemas and ActiveRecord. These will be the next things that appear on the site (of any notable length, anyway). I’m still wrapping my head around AR, but I find writing about something to be an excellent way to explore whether or not I really understand it as well as I think, so watch this space. You might want to grab the RSS feed (link’s only on the front page til I finish my template hacking).
Depending on who you’re asking, the "P" in LAMP could mean Perl, PHP or Python. You can just pretend there’s a leg messing to form an "R"…
I love the article! So far, everything you’ve said about how you go about learning seems so familiar to me. One of the things that I’ve been having the most trouble with is just understanding the relationship between the models, controllers and views. I get the basics, enough to create a basic app with a rigid MVC relationship, but I can’t quite grasp just how flexible the model really can be… and I get the feeling that that’s where the true power of Rails really lies.
Using the script/generate scaffold command is nice, since you can see and edit the scaffolding controller and view code. Be sure to read the fine print for this script though: it generates a controller with the plural form of your model, and it will overwrite any model definition you’ve already written.
So "ruby script/generate scaffold Recipe" will generate a "recipes_controller.rb". Curt’s OnLamp tutorial has you working with a Recipe controller, so this transition can be confusing. The scaffolding script will also generate a new Recipe model in your models directory, and will overwrite a recipe.rb file that’s in its way.
Hi Amy,
Great article and welcome on board!
I found one little glitch, tho: "Recipe is an object based off of the Recipes class (which uses the Recipes model)"
This is not quite true. Recipe is the class (they’re always capitalized) and find_all is a class method. Class method is a method that is not involved with individual objects like normal methods. Instead, it’s common for all objects of that class. The point of class methods is that you can call them even if there’s no object created. That’s exactly the case in your example.
There’s a good (and short) introduction to class methods (http://www.rubycentral.com/book/tut_classes.html#UE) in the free online version of "Programming Ruby", 1st edition (http://www.rubycentral.com/book/).
This is fantastic. I’m a designer starting to look into learning a language and Ruby(OnRails) looks promising. It’s very nice to see people writing human readable reference material. No offense intended to anyone at all. So thanks again!
Also this is a nice looking site! One nit: It might just be my overused eyes. But the #666 on pink text is a bit harder to read than I imagine you intend. Maybe bumping your .code text color back up to #000 would help?
Cheers, Alex
Great follow-on to the original article. One minor point, in the section "Variable: Where It’s At" you say: "Recipe is an object based off of the Recipes class (which uses the Recipes model)" In fact Recipe is a class that inherits from ActiveRecord::Base
Thanks for the informative Ruby on Rails articles (including the CMV stuff). I’m at least 6 weeks behind you but attempting to follow the same trail you are blazing.
Actually, I’m farther behind you than that. I learned basic programming in a university program that taught Pascal and can READ code better than I can write it (which isn’t saying a lot). I’ve been vacillating on what language(s) to actually spend time learning, but after all that I have read about Ruby on Rails (including this opinion article: http://defrang.com/index.php?story=829 ) it sure seems like Ruby and Ruby on Rails is a productive place to start.
Keep up the great work.
PS… know anybody that needs a Beseler 23CII ? : )
Hello…
thanks for this stuff.
I found another tutorial, Which may help other guys ! (note: it is a little bit old)
http://rails.homelinux.org/
again another thanks for the nice mix of colors and txt formating
Excellent article – which I found from Curt’s link at the start of his Part 2, on OnLAMP.
I had the same reactions to the original article, and have been slowly following up on building my own understanding. It’s frustrating how scattered the Rails documentation, examples, Howtos and tutorials is.
Hi Amy and everyone – an article to complement Curt’s tutorial.
ROR is quite exciting – I don’t get excited – and it’s definitely the right time for it.
There’s things I would like to see explained by someone, being a Ruby Noobie, such as paging of datasets 🙂
The API reference looks brilliantly comprehensive, although the presentation is bonkers – I’ll come back to it once I have a clue.
Missing are more real examples. The elegance of Rails makes me think that real examples will accelerate Rails work very quickly rather than having to repurpose code every single time to make it work with a specific database or data.
I’m a PHP and ActionScript guy, and I can see the brilliance in Rails immediately. I’m off now to spend some time figuring out how to do what I need to do 🙂 ttfn
If you don’t have the benefit of getting to make well designed tables with sensible naming conventions, but instead have to deal with a database mess you have inherited, the following things can be helpful…
If you want to make a ‘Story’ ActiveRecord, but your table is not called ‘stories’ (but ‘story’ or worse…), then you can override the table name in the model using:
def self.table_name() "strange_table_name" end
The same thing applies for the table’s auto increment id column:
def self.primary_key() "strange_id_name" end
Also, when defining foreign keys the ‘foreign_key’ option can be used:
belongs_to :author, :foreign_key => "not_author_id"
I haven’t really done any object oriented coding but I’m familiar with html, Perl,fortran and IDL. Any suggestions on where I can learn enough of the basics of OOC without having to learn all the details, so I can start to function with Ruby and Rails?
You say you would like to have children by Ruby. I am an embodiment of the spirit of Ruby and can accomodate you in that area. -jb
Great article! I’m just getting started with Rails and I’ve got the pre-requisite PickAxe II, but it’s great to get the 10,000 foot view before I really jump in. Great writing style too…kept me interested all the way through. I’ve got your feed and I’ll be checking back often. Can’t wait for your book. Thanks!!
As a web designer and programmer I’d rather user java, html and php 🙂 too much simpler than the huge amount of stuff you’ve got to install and configure for Ruby .
A pretty good Article !
I really, really hope that once I get around to playing with ruby that it is all its cracked up to be. Sort of like Java Struts for dummies.
I’m dreaming of a white christmas….
You can see the scaffolding Methods @
<a href=’http://rails.rubyonrails.com/classes/ActionController/Scaffolding/ClassMethods.html’>http://rails.rubyonrails.com/classes/ActionController/Scaffolding/ClassMethods.html</a>
It’s nice to see it layed out like that 🙂
Am I the one and only reader that came here wih Explorer 6 and would have preferred a marginLeft of 0px on div #content? I would recommend using standards when they are 🙂 (one table does it in seconds). Maybe sidebar should float, don’t know, I forgot: I did a three column CSS layout once and don’t want to do it again :-). Great tutorial. Thanks.
Hi Amy, your activerecord cheatsheet saved me today. Finally solved my problem. Would you be able to do a minor update to your pdf to point out what I finally found my problem to be? Read about it here: http://www.blainekendall.com/index.php/archives/2006/05/11/ruby-on-rails-active-record-gotcha/
Hi Amy, I have a suggestion for an update to your activerecord spreadsheet. A single letter makes all the difference. Read about it here: http://www.blainekendall.com/index.php/archives/2006/05/11/ruby-on-rails-active-record-gotcha/
You’re awesome Amy! Your articles are incredibly helpful and inciteful. Really well done!
Do you have any metrics on developer productivity when ruby on rails is used for web development?
Also any pointers on how to implement web services?
Good article! I’m getting started in rails, and it helped. I also am really starting to like Radrails, an eclipse-based IDE built around doing everything RAILS.
This is a great article. Well done. I too just got started with Rails and yoru passion is right on the money. A great read.
Many thanks.
So far, based on what I’m reading, Ruby on Rails is absolutely awesome.I don’t know where I’ve been, but I’ve just only noticed Ruby on Rails this week. I’m a Perl/PHP/Actionscript/Python programmer on the web. I’ve been so excited about all the possibilities for stuff that I had on my todo list.
My thanks to you and Curt Hibbs for the tutorials.
Great article. Spam makes me sad. LAMP with an extra leg is LAMR, which to a h4x0r (or a sn4x0r, for that matter) would spell lamer, so ixnay on that Robin, who posted three days later. Will anyone read this comment? Tune in next time and see.
Great introduction to Rails. Thanks!
I’m also starting with RubyOnRails, I hope to make my weblogs more dynamic. Also RubyOnRails seems to be great for the newbies.
You article is great, but i have to read it more carefully again … thanx 😉
All the best! AO from <a href="http://www.kaosaudio.com">KaosAudio</a>
Your post is great but antispam is not so good.
[…] Really Getting Started in Rails […]
[…] Really Getting Started in Rails […]
[…] https://slash7.com/2005/01/24/really-getting-started-in-rails/ A massive glossary of Ruby on Rails links […]
[…] Really Getting Started in Rails […]
[…] it up… made me a go-to when people working with Rails needed a designer who “got it.” Example, example, example, […]